Regular Specifications of Resource Requirements for Embedded Control Software

For embedded control systems, a schedule for the allocation of resources to a software component can be described by an infinite word whose ith symbol models the resources used at the ith sampling interval. Dependency of performance on schedules can be formally modeled by an automaton (w-regular language) which captures all the schedules that keep the system within performance requirements. We show how such an automaton is constructed for linear control designs and exponential stability or settling time performance requirements. Then, we explore the use of the automaton for online scheduling and for schedulability analysis. As a case study, we examine how this approach can be applied for the LQG control design. We demonstrate, by examples, that online schedulers can be used to guarantee performance in worst-case condition together with good performance in normal conditions. We also provide examples of schedulability analysis

What Petri Net Obliges Us to Say: Comparing Approaches for Behavior Composition

We identify and demonstrate a weakness of Petri Nets (PN) in specifying composite behavior of reactive systems. Specifically, we show how, when specifying multiple requirements in one PN model, modelers are obliged to specify mechanisms for combining these requirements. This yields, in many cases, over-specification and incorrect models. We demonstrate how some execution paths are missed, and some are generated unintentionally. To support this claim, we analyze PN models from the literature, identify the combination mechanisms, and demonstrate their effect on the correctness of the model. To address this problem, we propose to model the system behavior using behavioral programming (BP), a software development and modeling paradigm designed for seamless integration of independent requirements. Specifically, we demonstrate how the semantics of BP, which define how to interweave scenarios into a single model, allow avoiding the over-specification. Additionally, while BP maintains the same mathematical properties as PN, it provides means for changing the model dynamically, thus increasing the agility of the specification. We compare BP and PN in quantitative and qualitative measures by analyzing the models, their generated execution paths, and the specification process. Finally, while BP is supported by tools that allow for applying formal methods and reasoning techniques to the model, it lacks the legacy of PN tools and algorithms. To address this issue, we propose semantics and a tool for translating BP models to PN and vice versa.Comment: 14 pages, 10 figures, Published in IEEE Transactions on Software Engineering (IEEE TSE